Subject: DLUR Architecture Change Proposals Now Available For Review

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Thu, 16 Mar 95 11:17:35 EST

Proposals to change the APPN DLUR Architecture Reference manual have
been placed on networking.raleigh.ibm.com for items 8256, 8257, 8258,
8259, 8260, and 8261.  The files can be found in directory /aiw/dlur:

     abs8256.txt
     abs8257.txt
     abs8258.txt
     abs8259.txt (also includes 8260 and 8261)
     arch8256d.psbin
     arch8257d.psbin
     arch8258d.psbin
     arch8259d.psbin (also includes 8260 and 8261)

The individual items are as follows:

8256) Add XID1 support to DLUR/S

      The DLUR Architecture Reference (section 13.1.1.1) explicitly
      lists XID0 and XID3 as supported, while other sections, including
      the GDS X'1500' CV X'81' format, just say "XID image".

      The question of XID1 support has been raised.  The intent was not
      to leave XID1 support out of DLUR/S.  However, DLUS only
      implemented XID0 and XID3 support.  It is possible that some DLUR
      implementations may have done so too.

      To correct this omission, XID1 will be added to section 13.1.1.1
      as well as the XID format section in appendix C.

      VTAM has agreed to APAR XID1 support into its DLUS implementation.
      If DLUR implementations take any received XID and forward it to
      the DLUS regardless of XID format type, they will work without
      change.  Any DLUR implementation rejecting a received XID1 should
      change its implementation to accept and forward it.

      This item is documented in abs8256.txt and arch8256d.psbin

8257) Correct sense data encoding in DLUR protocol error alert

      Review comments of the APPN DLUR Architecture Reference Version
      1.1 from Data Connection Ltd. and IBM include the following:

         One of the sense data values used in APPN/DLUR Alert CPDL001
         is listed in section 4.6.1.1 as X'1001 0001' but in the
         previous section is listed as X'1001 0000'.  We believe that
         X'1001 0000' is correct.

      To correct this error, X'1001 0001' will be replaced with
      X'1001 0000' in APPN/DLUR Alert CPDL001.

      This item is documented in abs8257.txt and arch8257d.psbin

8258) Correct actions encoding and ordering in DLUR configuration
      error alerts

      Review comments of the APPN DLUR Architecture Reference Version
      1.1 from Data Connection Ltd. include the following:

         In the Actions for APPN/DLUR Alert CPDL002, the text states
         "Correct installation problem" with a coding of X'5100'.
         When testing with Netview, we found that it didn't recognize
         this code.  In looking at Formats, X'1500' corresponds to
         "Correct installation problem".

      To correct this error, X'5100' will be replaced with X'1500' in
      APPN/DLUR Alerts CPDL002, CPDL003, CPDL004, and CPDL005.

      Shortly thereafter, DLUR testing discovered an additional concern:

         In the MS Reference-style Alert tables, you're supposed to
         list the Recommended Actions for each of the User, Install,
         and Failure Causes groups right after that group.  This is how
         the tables indicate whether the Recommended Actions belong in
         the X'94', X'95', or X'96' SV.

         This problem occurs in all four of the configuration error
         Alerts.  Currently the tables read:

               User Causes       (none)
               Install Causes    <<various code points>>
               Failure Causes    (none)
               Actions (note 1)  X'1500'

         They should read:

               User Causes       (none)
               Install Causes    <<various code points>>
               Actions (note 1)  X'1500'
               Failure Causes    (none)

      To correct this error, the order of the Failure Causes and Actions
      will be swapped in APPN/DLUR Alerts CPDL002, CPDL003, CPDL004,
      and CPDL005.

      This item is documented in abs8258.txt and arch8258d.psbin

8259) Further clarify DLUR processing of short RSP(BIND) RUs

      Review of AIW item 8218 discovered a problem in the description
      of setting the RSP(BIND) pacing fields when constructing a short
      RSP(BIND).

      The pacing fields are supposed to be set for the REX (SLU) stage,
      but the current description details the process for setting the
      APPN (PLU) stage.

      The proposed solution is to replace the DLUR architecture
      reference section on setting the pacing fields in "short RSP
      (BIND) processing" with the following:

         - setting the pacing fields in the RSP(BIND) for the REX stage
           to the BIND request values

      Subsequent processing (actually the section that's currently in
      the document about setting the pacing values for the PLU stage)
      would take the REX stage values and change them to the PLU stage
      values.

      This item is documented in abs8259.txt and arch8259d.psbin

8260) Add DLUR processing of Whole BIUs Required Indicator (WBRI)

      Christine Martin of Data Connection Ltd. asked whether the WBRI
      setting in an extended short RSP(BIND) should not reflect the
      segment reassembly support of the DLUR.

      The problem statement is as follows:

         I've got a quick question about the recent clarification to
         the DLUR architecture for extending short positive response
         BINDs.  The clarification states that converting the short
         +RSP(BIND) into an extended short form RSP(BIND) includes:

            - setting the whole-BIUs required indicator on if the
              RSP(BIND) will be reextended.

         From looking at formats, setting this bit on (1) means that the
         sending node doesn't support receipt of segments on this
         session.  Shouldn't this be set off (0) indicating that the
         sending node supports receipt of segments on this session?
         (I notice that the formats state that the bit is reserved for
         non-extended, non-LU 6.2 BINDs - so again, wouldn't it be set
         to 0?)

      The current description was derived from the NCP BF
      implementation.  It turns out that NCP always sets WBRI on
      because NCP never reassembles segments at its BF.  However, a
      DLUR BF should have as an implementation option segment reassembly
      support and should then set the WBRI according to its own segment
      reassembly capabilities.  This could be done both on RSP(BIND)s
      built by the DLUR as well as received by the DLUR.

      What needs clarification in DLUR architecture is how to set WBRI
      based on DLUR's capabilities.

      The proposed solution is to replace the WBRI section in "short
      RSP(BIND) processing" in the DLUR architecture reference with a
      new section on "WBRI processing" within the RSP(BIND) section; it
      would include the following:

         * WBRI processing - a DLUR can, as an implementation option,
           support segment reassembly at its BF; whether or not a DLUR
           provides this support is reflected in how it sets the Whole
           BIUs Required Indicator (WBRI) - WBRI=0 means sending node
           supports receipt of segments on this session while WBRI=1
           means sending node does not support receipt of segments
           (this processing could apply to RSP(BIND)s built as well as
           received by the DLUR):

              - if WBRI is valid (not a reserved field), use the
                received value
              - if WBRI is reserved, act as if DLUR received WBRI=1
              - if WBRI=1 and DLUR BF can support segment reassembly,
                set WBRI to 0
              - if WBRI=1 and DLUR BF can't support segment reassembly,
                set WBRI to 1;

      This item is documented in abs8259.txt and arch8259d.psbin

8261) Add DLUR processing of extended UNBIND RUs

      DLUR testing uncovered a condition not described in the
      architecture, specifically how the DLUR BF should process
      extended UNBIND RUs when the dependent LU can only handle
      unextended UNBINDs.

      The problem statement is as follows:

         I've run across a problem with "extended" UNBINDS.
         When we receive a Bind for a DLuR LU we unextend it,
         send it to the LU, then extend the ensuing +rsp(Bind).
         Since we've accepted an extended Bind, Vtam will send an
         "extended" Unbind.  Currently, there is no code to
         unextend Unbinds and so the Unbind is sent as is to the LU.
         The LU however is ( for some reason ) checking the length of
         the RU, and since it never expects Unbinds longer than 6 bytes,
         it rejects the RU and brings down the session.  In most cases
         we're taking down the session anyway, but not in the case of a
         NetView logon. NetView sends an "UNbind with a bind forthcoming
         type of Unbind.  Since the LU is bringing down the session, the
         "forthcoming Bind" is also rejected.
         So, do we need to add code in the DLuR to "unextend" Unbinds??
         or Is this a bug in the LU code for not accepting the Unbind
         and just ignoring the extra data (CV60) ??

      NCP BF takes an extended UNBIND and unextends it when necessary.

      What needs clarification in DLUR architecture is when and how to
      convert an extended UNBIND into an unextended UNBIND.

      The proposed solution is to update the DLUR architecture reference
      section on "LU-LU Session Deactivation" with the following:

         The UNBIND will be unextended if necessary, based on the
         extended BIND support indicators in the CV X'0C' in the
         +RSP(ACTLU) - this involves:

             * all UNBIND types except X'FE' - truncating the UNBIND
               RU to only the request code plus the UNBIND type;

             * UNBIND type X'FE' - truncating the UNBIND RU to only the
               request code, the UNBIND type, and the sense data.

         No reextending of the RSP(UNBIND) is required.

      This item is documented in abs8259.txt and arch8259d.psbin

I'm requesting approval of these items at the next AIW in May during the
APPN Reference SIG session.

Ed Tremblay